


Conlangs and Accessibility

by Addleton



Category: No Fandom
Genre: Coding Guide, Conlang, Fanwork Research & Reference Guides, Translation, accessibility
Language: English
Status: Completed
Published: 2020-11-07
Updated: 2020-11-07
Packaged: 2021-03-09 00:15:44
Rating: Not Rated
Warnings: No Archive Warnings Apply
Chapters: 1
Words: 1,648
Publisher: archiveofourown.org
Story URL: https://archiveofourown.org/works/27435700
Author URL: https://archiveofourown.org/users/Addleton/pseuds/Addleton
Summary: A Quick Guide to Making Translations Accessible on AO3





	Conlangs and Accessibility

# Introduction

Handling constructed languages, and even multiple languages within the same work, is challenging. How do you make sure your translations are easily accessible for those who need them without being obtrusive to those who don't? What do you do if most of your dialogue is in a different language compared to just a few words here and there? How do you accommodate the full spectrum of devices people use to read fics? 

Hopefully this guide helps you make your translations as accessible as possible.

# Inline Methods

### AKA the Definition (dfn) Method

The simplest method of including unobtrusive inline translations is to use the **dfn** element with the **title** attribute which allows readers to hover over the text and read a tooltip translation.

> <dfn title="Your translation goes here.">Text to be translated goes here.</dfn>

The result:

> Text to be translated goes here.

The biggest drawback of **dfn** is that it requires some sort of on-screen pointer to work (i.e. it's not mobile-compatible).

There are other methods which employ CSS to provide on-click/-tap translations which are mobile-compatible, however, these methods are messy to code and keep track of, requiring a separate work skin for each work/chapter, in addition to not being compatible with most screen readers. Additionally, editing to accommodate revisions to the text is often a nightmare with these methods.

For those reasons, I'm not going to touch on CSS methods in this document, aside from mentioning that they exist and aren't fully accessible.

# Mobile Browsers and Keyboard Navigation

### AKA the Hyperlink Method

The simplest method that is mobile- and keyboard-compatible is to use in-text hyperlinks with an appendix of translations. Note that there is a length limit for endnotes on AO3, so unless you're only translating a few words, I recommend sticking your appendix at the end of the work/chapter itself (even though having it in the endnotes would be visually more pleasing _and_ not inflate your word count).

The greatest strength of the hyperlink method is that it can easily be adjusted to better support screen readers. As a result, this is the translation method I consider to be the best and most accessible, even though it does require a fair amount of coding.

I also recommend linking the entire phrase to be translated rather than having a linked reference at the end of the phrase. There are several reasons, but the most important is that linking the whole phrase gives the people using screen readers the option to reliably skip past the gibberish their readers will spit out.

The hyperlink method uses the **anchor** tag and the **href** , **name** , and **id** attributes. _**Both**_ **name** and **id** are required for this method to work, even though they will have identical properties, and this is enforced by AO3's parser. If you forget the **name** or **id** in one tag, the parser deletes the property entirely.

> <a href="#translation" name="#text" id="#text">This is the text to be translated.</a>
> 
> <h2>Translations</h2>
> 
> <a href="#text" name="#translation" id="#translation">This is the translation.</a>

The **name** / **id** can contain numbers and letters. Avoid special characters and punctuation other than dashes (-) and underscores (_). Additionally, the **name** and **id** _must be unique for each link_.

Now, while the above code works, the one major downside is that it brings the reader back to the _start_ of the first link, forcing the reader to skim through the untranslated text again to get back into their reading. This is particularly inconvenient for someone using a screen reader.

If you want to create a more immersive experience where the translation link jumps to the _end_ of the first link, you will need to add a second **anchor** tag after the untranslated text and make _that_ the return point with **name** and **id**.

> <a href="#translation">This is the text to be translated.</a><a name="#text" id="#text"></a>  
>  <a href="#second">This is more text to be translated.</a><a name="#more" id="#more"></a>
> 
> <h2>Translations</h2>
> 
> <a href="#text" name="#translation" id="#translation">This is the translation.</a>  
>  <a href="#more" name="#second" id="#second">This is the second translation.</a>  
> 

For a real-life demonstration of how this method works, you can check out my work [Su'cuy Gar](https://archiveofourown.org/works/26705863) where the majority of the dialogue and a few in-line terms were written in Mando'a.

# Screen Readers

### Hyperlink Method + ARIA Attributes

If you're truly committed to making your work screen reader accessible, there are additional bits of code called **ARIA attributes** which exist specifically for accessibility. ARIA attributes can be added to any HTML tag and are particularly useful for links. Using ARIA attributes also requires minimal coding if you are already using the hyperlink method for your translations.

Unfortunately, ARIA attributes are not supported on AO3 at this time, but I recommend looking them up regardless in the hopes that one day they will be supported. I particularly recommend checking out the **aria-label** , **aria-labelledby** , **aria-describedat** , and **aria-describedby** attributes and use cases.

# Keyboard and Low-Vision Link Navigation

### Hyperlink Method + CSS BORDER Property

For folks with limited dexterity who can't use a mouse or tiny touchscreen, keyboards are often the tool of choice for navigating the internet. The presence of multiple links close together can be difficult to navigate by keyboard, especially when the links are not visibly differentiated while focused on. This lack of link visibility also affects low-vision readers.

This is very easy to fix by using the **a:active** , **a:focus** , and **a:hover** CSS pseudo-classes and the **border** property in a custom work skin.

> 
>     #workskin a:active,  
>     > 
>     #workskin a:focus,  
>     > 
>     #workskin a:hover {  
>     > 
>     border: 3px solid;  
>     > 
>     margin: -3px;  
>     > 
>     }

Hover or press and hold this sentence to see the result. This link should be clearly separate from the other links. The -3px margin is there to offset the size of the 3px border. Without it, the border would push all the text after it over by 6px, which can be a bit visually jarring.

# Streamlining the Process

### AKA Minimizing the Amount You Have to Code

So you've got a lot to translate and even more to code, but you've never coded this much before. Or, you find that spellcheck is an essential tool and so do all your fic writing in a word processor that even does the fancy quotes for you but makes using simple quotes a nightmare.

That's okay. There are ways to automate the process so you don't have to manually add in the same stuff over and over again, and you don't even need a special program or app to use one of them.

## Method 1: Find and Replace

Find and Replace is thankfully a standard feature in most text editors and word processors. With a bit of planning, you can use it to cut down dramatically on the amount of coding you have to do.

My personal favorite method is to use 2-4 special characters I know I will _not_ be using elsewhere in the document. One character is used to mark the start of the hyperlink while the second is used to mark the end. Once the document is complete and revised, you can then run Find and Replace to add in the basic coding.

> ^This is the text to be translated.&
> 
> <h2>Translations</h2>
> 
> %This is the translation.+
> 
> Find: ^  
>  Replace: <a href="#">
> 
> Find: &  
>  Replace: </a><a name="#" id="#"></a>
> 
> Find: %  
>  Replace: <a href="#" name="#" id="#"></a>
> 
> Find: +  
>  Replace: </a>

Afterwards, you would only need to add in the unique name and id (which are the same) plus the link reference (the name/id of the translation) to each instance.

> <a href="#">This is the text to be translated.</a><a name="#" id="#"></a>
> 
> <h2>Translations</h2>
> 
> <a href="#" name="#" id="#">This is the translation.</a>

## Method 2: Use a Code Editor

Code editors are essentially glorified text editors with several features that make coding _so_ much easier. I strongly recommend using one if you write a lot of dialogue in a conlang because autocomplete, automatic closing tags, and multi-point selection are _beautiful_ time-saving things.

Not all code editors have all those features, however, so be sure to look for them specifically if none of the code editors I recommend below work out for you.

### Atom

[The Atom text editor](https://atom.io/) is free and open source. It's also very reliable while also being incredibly customizable. It works on Windows, Mac, and Linux, in addition to Chrome OS with a bit of finagling.

### Sublime Text 3

[The Sublime Text 3 code editor](https://www.sublimetext.com/3) is considered by many to be the best code editor around. It is lightweight and customizable with a lot of useful coding features. Its one downside is that it is not free, although there is an indefinite free preview available. If you really like using it, though, support the developers and drop the one-time fee of $80 (at the time of writing) for the full license.

Sublime Text 3 is available on Windows, Mac, and Linux.

### Visual Studio Code

Unlike the previous two recommendations, [Visual Studio Code](https://code.visualstudio.com/) is a full Integrated Development Environment (IDE). What this means is that Visual Studio Code has all the features you'll need and then some as it is designed to code applications from the ground up. Due to the sheer number of features available, it's not the easiest to learn or initially use, but if you happen to code in other languages and want an environment that supports HTML in addition to whatever your language of choice is, Visual Studio Code is an excellent and completely free option.

This is what I personally use because being able to edit the HTML for my fics in the same application I code in is convenient, and Visual Studio Code's HTML support is some of the best I've experienced.

Like the other two, Visual Studio Code works on Windows, Mac, and Linux.


End file.
